@jhorvath with the review in #8034 multiple questions/problems are raised:

• Why do we need 41(!) MB to deploy to somewhere?
• Why are there multiple http clients in use?
• The license file for libs.fabric8 is wrong (name, description, license) it looks dubious, that all jars have the same origin, author and license.

The license file must be fixed and I think the whole implementation needs rethinking. If every cloud vendor adds 40MB, we will hit limits quickly:

• Google Cloud Computing
• AWS
• Oracle Cloud Infrastructure
• Microsoft Azure

Are the first global player, but then why stop there? I want my local cloud infrastructure supported as well, so

• Ionos
• Schwarz IT Cloud Services
• Hetzner Cloud
• Stackit

Ok, only 320MB, but that was global + a short list from germany.

So what is the plan here?

@matthiasblaesing To clarify, this pull request adds 16.5MB of external dependencies. The Fabric8 library provides generic Kubernetes support and is compatible with all cloud providers worldwide. As such, the total remains 16.5MB. We plan to retain Fabric8 because it offers the smallest possible set of external dependencies.

And I'll check the license

@jhorvath yes I understand this. I looked at the only user of fabric8 and that is cloud.oracle. cloud.oracle brings in a whopping 26MB and libs.fabric8 14MB. The difference is a rounding error.

We plan to retain Fabric8 because it offers the smallest possible set of external dependencies.

@jhorvath I'm curious who the "we" is in that sentence, as multiple members of the Apache NetBeans PMC seem to be querying that plan currently. That conversation should probably end up in a dev@ thread rather than at the bottom of a closed PR though.

If I understand this correctly, the JARs contain structures binding JSON structures. If I remember correctly, I saw such monster JARs generated from the SOAP interface for VMWare VSphere. In the end we decided to bite the bullet and accept the huge JAR as that made the development much more manageable.

So the question is:

Do we really need all the JARs (The OCI bindings give me more worries, than generic Kubernetes, as the latter is indeed multi-vendor) and how much work would it be to directly build the JSON structures or bind a subset directly with jackson?

The size of the sigfile could be worked around by not generating a sigfile.

In this PR, only the JARs required to support Kubernetes were added. Regarding whether all of these are necessary: yes, they are. The Kubernetes API is complex, and implementing all the required calls at the REST level is beyond the scope of a single developer.
I also hope that either I or another community member will use Fabric8 for additional Kubernetes integrations (not specific to any cloud provider). There are numerous potential features, such as deploying applications or starting a remote debug session.
As for OCI, I am not aware of any other cloud provider planning to add support for its infrastructure. If that happens, it would be better to find a way to share a single code base rather than creating a separate fork for each new provider. Directly binding a subset of structures with Jackson might be possible, but it would significantly increase development effort and maintenance complexity. For now, the added JARs strike a balance between manageability and functionality.
The OCI libraries were added two years ago, and the discussion doesn't belong in this PR, in my opinion.

In this PR, only the JARs required to support Kubernetes were added. Regarding whether all of these are necessary: yes, they are. The Kubernetes API is complex, and implementing all the required calls at the REST level is beyond the scope of a single developer.

@jhorvath Agreed, proposals which would try to generate or re-implement the k8 model would pretty much guarantee a veto from me since this would be both unmaintainable and also not observable given the API footprint. Using the dependency is the lesser evil there but I would rather try to find ways to avoid this situation entirely.

NetBeans was always known for good tooling integration - do doubt. However, this can often also be achieved by integrating with the project build or tools in the environment. A project will likely know how to deploy itself to a cluster since nobody deploys IDEs to CI. NB already bundles maven and gradle which could delegate to plugins. Maybe it can call the cli tool. Delegating to projects, if possible, is often the ideal solution since they know exactly what versions they have to work with.

@sdedic @jhorvath Regarding the dependencies specifically. We do know that there is no dependabot and nothing what makes dependency updates a one-click operation in this repo. By integrating this, there is also the shared responsibility (esp from those who approved and merged) to keep those dependencies up to date before releases. We have a manually triggered dep checker workflow, but thats where the convenience ends unfortunately.

@matthiasblaesing already mentioned it, but this does also add yet another http client which is not ideal from the attack surface perspective. Please check if there is a java.net.http variant, if not, please have especially an eye on that dependency between releases.

I would like to steer the debate to be more constructive. Oracle Cloud SDK is here since January 2022 and was properly reviewed by @matthiasblaesing and @JaroslavTulach before it was merged into master. For reference, see PR #3352.
Regarding the recent addition of the Fabric8 library, my decision was based on extensive testing. Compared to the CLI, Fabric8 is approximately 100 times faster and significantly more reliable, particularly for operations like port forwarding. While Gradle and Maven plugins are well-suited for CI/CD, they don’t provide the seamless, quick deployment experience that developers expect when deploying directly from an IDE. Fabric8 excels in this scenario, delivering a smoother and more efficient user experience. It has also lower number of transitive dependencies than the official Kubernetes Java Client. The only drawback is that it doesn't support a java.net.http clients.
As for dependency management, I understand the concerns. When adding the OCI SDK, I saw the mess firsthand and cleaned up several duplicate libraries during the process.

The only drawback is that it doesn't support a java.net.http clients.

Actually it does: https://central.sonatype.com/artifact/io.fabric8/kubernetes-httpclient-jdk

..based on extensive testing. Compared to the CLI, Fabric8 is approximately 100 times faster and significantly more reliable, particularly for operations like port forwarding. While Gradle and Maven plugins are well-suited for CI/CD, they don’t provide the seamless..

Adding a few points like this to a PR is very helpful to communicate why something is implemented how it is. The dependencies were noticed during API snapshots and all we could see was one sentence and a sig file with 130k lines (and some license issues which are now resolved). Lets try to do open source properly.